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Abstract 

Our  milestones  for  this  pilot  project  were  to  collect  additional  interaction  records 
of  planning  by  two  agents,  to  analyze  the  actions  and  action  relations  in  the  data, 
to  refine  definitions  of  action  relations  to  represent  adequately  the  relationships 
occuring  in  the  data,  and  to  prepare  a  report  summarizing  the  major  findings  from 
the  analysis  and  presenting  the  new  action  relationships.  We  analyzed  data  from 
the  following  three  sources:  a  construction  task,  a  group  planning  meeting,  and  a 
simulated  human-computer  problem-solving  dialogue.  A  description  of  this  data, 
the  results  of  the  analysis,  and  the  proposed  new  action  relations  are  described  in 
this  report.  A  paper  describing  these  results  (Balkanski,  Grosz,  and  Sidner,  ■' Action 
Relations  in  Collaborative  Activity”)  will  be  submitted  to  AAAI-90. 


Action  Relations  in  Collaborative  Activity 

Cecile  T.  Balkanski,  Candace  L.  Sidner,  Barbara  J.  Grosz 


1  Data  Collection 

Our  initial  description  of  a  framework  for  modelling  collaborative  activity  included 
definitions  of  a  small  set  of  action  relations  [GS89].  These  relations  provided  a 
way  of  constructing  more  complex  actions  from  simpler  ones.  For  instance,  the 
complex  action  of  George  and  Sue  lifting  their  dining  room  table  could  be  defined  in 
terms  of  a  simultaneous  generation  relationship  holding  between  George’s  lifting  one 
end  and  Sue’s  lifting  the  other.  We  noticed,  however,  that  to  model  collaboration 
required  a  more  complete  specification  of  a  wider  range  of  action  relations  that  might 
participate  in  any  collaborative  activity.  To  expand  the  set  of  relations  to  a  set  that 
would  span,  or  more  completely  span,  the  space  of  complex  collaborative  actions,  we 
investigated  data  in  three  domains:  a  construction  task,  a  group  planning  session, 
and  a  simulated  human-computer  problem-solving  dialogue. 

The  construction  task  data  were  taken  from  a  videotape  of  the  construction  of 
a  porch  swing  glider  by  two  agents;  we  will  refer  to  this  data  as  the  “glidertape 
data” .  The  group  planning  session  data  are  from  an  audiotape  of  three  individuals 
in  a  working  group  meeting  who  were  exchanging  information  about  the  month-to- 
month  maintenance  of  a  communication  network;  we  will  refer  to  this  data  as  the 
“meeting  data.”  These  two  types  of  data  differ  in  significant  ways:  the  glidertape 
data  includes  many  examples  of  physical  actions,  action  sequences,  and  rationales 
for  performing  actions;  it  also  demonstrates  the  interleaving  of  planning  and  act¬ 
ing  (including,  but  not  limited  to,  situations  in  which  actions  fail  to  achieve  their 
intended  effects)  that  we  conjectured  was  central  to  collaborative  activity.  The 
meeting  audiotape  discourse  centers  on  sharing  information  about  past  actions, 
and  to  a  lesser  extent,  choosing  actions  to  be  performed  at  a  subsequent  time.  The 
meeting  data  includes  extremely  useful  discourse  (communication)  data,  but  much 
less  data  about  the  interrelationships  among  physical  actions.  The  human-computer 
problem-solving  dialogue  data  is  a  set  of  dialogues  between  two  agents  collaborating 
to  manage  a  network  on  a  daily  basis.  This  data  was  constructed,  but  it  was  based 
on  discussions  with  network  managers  as  well  as  examples  in  the  literature.  This 
third  source  of  data  included  two  complex  action-types  not  uncovered  in  the  other 
two  domains:  iterations  and  conditionals. 

We  have  decided  to  choose  network  management  (at  the  daily  level)  as  a  domain 
of  application.  This  domain  has  several  characteristics  which  we  found  valuable  for 
our  research.  It  offers  a  natural  way  to  investigate  collaborations  among  agents,  one 
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of  which  could  be  a  computer.  It  requires  action  relationships  of  some  complexity, 
thereby  enabling  us  to  test  the  action  relations  we  define.  The  domain  also  offers  a 
means  of  exploring  the  coordination  of  graphical  and  linguistic  means  of  communi¬ 
cating  between  agents,  a  set  of  issues  we  are  investigating  under  sponsorship  of  U 
S  West  Advanced  Technologies. 

In  the  following  sections  most  of  our  examples  draw  on  data  from  the  glider- 
tape,  but  we  also  use  the  network  management  dialogues.  We  also  have  incorporated 
other  problematic  examples  from  the  commonsense  everyday  world  when  they  best 
illustrate  certain  problems.  The  relations  we  report  on  here  are  sufficient  for  de¬ 
scribing  the  relations  in  the  glidertape,  and  they  cover  nearly  all  of  the  relations  of 
the  network  management  dialogues.  We  are  still  investigating  the  representation  of 
tests  and  the  actions  they  comprise.  In  a  related  report[GSL89],  we  present  samples 
of  the  recipes  (i.e. act-types  and  relations  among  them)  for  actions  in  the  network 
management  domain. 

2  Action  Relations 

2.1  Introduction 

Our  aim  in  this  section  is  to  identify  and  define  the  relations  that  hold  among 
actions  performed  by  more  than  one  agent.  In  previous  work  [GS89],  we  have 
examined  generation  and  enablement  relationships  between  actions  performed  by  a 
single  agent.  For  example,  flipping  the  light  switch  generates  turning  the  light  on, 
and  buying  ingredients  enables  preparing  dinner. 

When  multiple  agents  and  multiple  actions  are  considered,  then  new  action 
relations  come  into  play.  For  example,  actions  performed  by  different  agents  may 
be  simultaneous  or  sequential.  In  our  earlier  work,  we  identified  the  following  cases: 

GEN-Simult:  two  agents  lifting  up  a  piano 

GEN-Conjoined:  two  agents  setting  a  table 

GEN-Sequence:  one  agent  turning  a  door  knob  then  pulling 

on  it  to  open  a  door 

The  glider  tape  provides  numerous  examples  of  actions  fitting  into  the  categories 
given  above,  els  well  as  examples  showing  the  need  to  revise  them  and  add  new  ones. 
In  this  section,  we  discuss  the  following  categories: 

Action  relations:  generation  (GEN),  enablement  (ENABLE), 

facilitation  (FACIL),  prevention  (PREVENT),  causality  (CAUSE) 

Complex  action  formation:  sequence,  conjunction,  simultaneity,  iteration 
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2.2  GENERATION 


If  action  A  generates  action  B  then  when  some  agent  G  performs  action  A,  action  B 
occurs  at  the  same  time,  without  agent  G  having  to  do  anything  more  than  perform 
action  A  [Pol86,Gol70].  For  example,  with  a  single  agent  and  action,  we  have  the 
example  given  earlier: 

GEN(flip(G,  light-switch),  turn-on(G,  light)) 

Or,  to  take  an  example  from  the  glider  tape,  the  action  of  one  agent  hammering 
each  arm-assembly  against  the  base  leg  assembly,  to  bring  the  two  pieces  tightly 
together,  can  be  represented  as  follows: 

GEN(hit(G,  arm-assembly,  hammer),  secure(Gi, arm-assembly, leg-spreader)) 

This  representation,  as  well  as  the  following  ones,  will  be  formalized  in  the  next 
chapter.  For  the  time  being,  it  suffices  to  read  GEN(A,  B),  as  A  generates  B. 

With  multiple  actions  and  agents,  we  need  to  specify  how  different  actions 
Ai,  A2,  ...,  A„,  performed  by  different  agents,  can  combine  to  produce  a  composite 
action  B. 

2.2.1  GEN-Simultaneous 

As  the  name  suggests,  simultaneous  actions  are  those  which  occur  over  identical 
intervals  of  time.  Each  individual  action  will  have  the  proper  generation  relationship 
with  the  overall  action  to  be  achieved  if  and  only  if  the  other  actions  are  performed 
at  the  same  time  [GS89]. 

For  example,  to  attach  the  arm-assemblies  to  the  base  of  the  glider,  the  agents 
perform  the  simultaneous  actions  of  holding  the  arm  assembly  in  the  vertical  posi¬ 
tion  and  attaching  it  to  two  glider  straps  mounted  to  the  base  of  the  elider.  This 
can  be  expressed  as  follows: 

GEN-Simult((hold(John,  right-arm-assembly, vertical-position'  Kc 
attach(Paul, right-arm-assembly,  right-strap)). 
attach(John&Paul,  right-arm-assembly,  glider-base)) 

The  number  of  actions  and  the  number  of  agents  need  not  be  the  same.  To 
attach  the  base  spreader  to  the  leg-assemblies,  for  example,  one  agent  performs  two 
actions  simultaneously  to  achieve  the  desired  result: 

GEN-Simult((hold(John,  left-hand,  left-end-, preader)  & 

insert(John,  right-hand,  lag-screw,  left-end-spreader)), 
attach(John,  left-end-spreader,  left-leg-assembly)) 
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2.2.2  GEN-Sequence 


Actions  related  by  a  GEN-Sequence  relation  are  those  that,  when  taken  together 
and  performed  in  a  particular  order,  achieve  a  desired  result.  [GS89]. 

For  instance,  the  recipe  for  making  an  angle-food  cake  can  be  described  (at  a  very 
high  level  of  description)  as  “preheat  the  oven,  make  the  batter,  bake  the  batter”. 
The  first  two  actions  are  related  by  a  GEN-Sequence  relation:  the  preheating  action 
must  be  done  before  the  making  the  batter  action  (else  the  batter  will  fall  while 
the  oven  is  heating  up),  but  the  former  does  not  enable  the  latter.  The  enable 
relationship  (described  later  in  this  chapter)  that  does  hold  in  this  recipe  is  between 
the  sequence  of  the  two  first  actions  and  the  third  action,  baking  the  cake.  We  can 
express  these  relationships  as  follows: 

GEN-Sequence((preheat(G,  oven)  A  make(G,  batter)),  ready-to-bake(batter)) 

ENABLE(ready-to-bake(batter),  bake(G,  batter)) 

GEN(bake(G,  batter),  make(G,  angel-food-cake)) 

If  two  or  more  actions  must  be  done  in  sequence,  then  there  is  a  reason  for  this 
ordering.  This  is  why  GEN-Sequence  and  Enable  relationships  are  sometimes  hard 
to  distinguish.  In  the  previous  example,  the  oven  needs  to  be  turned  on  before 
making  the  batter  so  that  it  is  at  the  right  temperature  when  the  batter  is  ready. 
This  is  a  time  constraint,  but  the  two  actions  are  not  related  by  enablement.  (One 
could  put  the  batter  in  a  cold  oven,  and  bake  it,  but  the  result  would  not  be  the 
expected  one.) 

However,  in  the  glider  tape,  there  are  very  few  instances  of  actions  related  by 
GEN-Sequence  relationships.  This  may  be  a  consequence  of  the  type  of  task  being 
performed,  namely  a  construction  task,  where  each  building  step  typically  enables 
the  next.  Consider  for  example  the  following  (high  level)  instructions: 

To  build  the  glider: 

1.  build  the  base 

2.  attach  the  arm  assemblies 

3.  attach  the  seat  frame 

4.  attach  the  back  rest 


Although  this  set  of  instructions  involves  a  “sequence”  of  actions,  describing 
these  actions  by  a  GEN-Sequence  relationship  would  be  incorrect:  here,  each  indi¬ 
vidual  action  involves  putting  together  particular  pieces  that  need  to  be  together 
in  order  for  the  next  action  to  be  performable.  We  therefore  have  a  set  of  actions 
related  by  enablement. 
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Another  reason  for  which  actions  may  have  be  to  sequential  is  resource  allo¬ 
cation.  For  example,  the  last  step  in  building  the  base  of  the  glider  consists  in 
tightening  all  bolts  and  screws.  So  far,  the  agents  have  been  working  simultane¬ 
ously,  on  of  the  right  side  and  the  other  on  the  left  side  of  the  structure  being 
constructed.  But  in  this  step,  they  work  in  sequence  because  they  have  to  share 
the  (single)  nutdriver  they  have  available.  Here,  Paul’s  tightening  the  screws  on  the 
left  side  does  not  enable  John  to  tighten  the  screws  on  the  right  side,  therefore,  we 
have  a  GEN-Sequence,  namely: 

GEN-Sequence((tighten(Paul,  screws,  left-side),  tighten(John,  screws,  right-side)), 
tighten(Paul&John,  screws,  glider-base)) 

2.2.3  GEN-Conjoined 

Conjoined  actions  are  those  that,  when  taken  together,  but  performed  in  any  order, 
achieve  a  desired  result.  In  such  cases,  the  time  interval  for  each  individual  action 
must  fall  within  some  time  interval  during  which  all  actions  are  performed;  these 
individual  actions  may  overlap,  but  there  is  no  need  for  simultaneity,  nor  for  a 
predetermined  order  of  performance  of  the  individual  actions  [GS89]. 

For  example,  at  the  beginning  of  the  glider  tape,  after  opening  the  box  and 
emptying  its  contents,  the  agents  clear  the  floor  in  order  to  have  enough  space  for 
building  the  glider.  This  clearing  action  is  achieved  by  pushing  aside  the  box  and 
the  pillows  which  came  with  it.  These  two  actions,  when  taken  together,  achieve 
the  desired  result,  as  described  in  the  following  representation: 

GEN-Conjoined((push-aside(Gl,  pillows)  &  push-aside(G2,  box)), 
clear(Gl&G2,  floor)) 

Another  example  occurs  when  the  agents  are  building  the  base  of  the  glider. 
One  of  the  first  subtasks  consists  in  placing  dowels  in  the  front  and  rear  rails.  This 
is  accomplished  by  Paul  putting  them  in  the  right  ends,  and  John  in  the  left  ends; 
there  is  no  need  for  them  to  perform  their  actions  during  exactly  the  same  time 
intervals: 

GEN-Conjoined((place(Paul,  dowels,  right-end-of-rails)  & 
place(John,  dowels,  left-end-of-rails)), 
prepare(Paul&John,  dowels,  rails)) 
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2.2.4  GEN-Iteration 

Another  type  of  action  relation  which  was  clearly  illustrated  in  the  glider  tape  is 
that  of  iteration.  In  this  case,  one  or  more  agents  perform  the  same  action  over  and 
over,  until,  for  instance,  every  object  of  a  given  set  has  been  manipulated  by  that 
action.  This  repetition  happens,  for  instance,  when  the  agents  are  checking  all  the 
screws.  To  accomplish  this  task,  they  have  to  take  every  screw,  one  at  a  time,  and 
match  it  on  the  list  of  parts  in  the  directions  sheet.  We  can  express  this  as  follows: 

GEN-Iteration((find(screw,)  &  match  (screw,-,  picture)),  check(set-of-screws)) 

An  action  to  be  iterated  can  itself  be  a  complex  action.  For  example,  to  tighten 
all  the  bolts,  the  agents  have  to  perform  the  tightening  action  on  each  bolt.  This 
action  is  a  complex  action  which  can  be  described  by  a  GEN-Simult  relationship: 
to  tighten  a  bolt,  John  and  Paul  must,  simultaneously  and  respectively,  hold  the 
nut  and  turn  the  bolt.  This  is  expressed  as  follows: 

GEN-Simult((hold(John,  nut)*&  turn(Paul,  bolt)),  tighten(John&Paul,  bolt)), 

GEN-Iteration(tighten(John&Paul,  bolt,-),  tighten(John&Paul,  set-of-bolts)) 

Although  all  examples  from  the  glider  tape  involve  iteration  over  a  set  of  objects, 
this  is  not  the  only  type  of  iterative  actions.  One  other  type  of  iteration  involves 
repeating  an  action  until  a  given  condition  is  met,  as  in  the  following  example: 

Try  the  number  until  you  get  through! 

Here,  unlike  the  other  examples,  it  is  not  known  ahead  of  time  how  many  times 
the  action  will  be  iterated.  The  next  chapter  will  discuss  these  cases. 

2.3  ENABLE 

If  action  A  enables  action  B,  then  the  performance  of  action  A  brings  about  condi¬ 
tions  that  allow  the  subsequent  performance  of  B.  Unlike  generation  of  B  from  A,  if 
A  enables  B,  B  is  not  done  as  a  result  of  doing  action  A  [Pol86,Gol70],  For  example, 
with  a  single  agent  and  action,  we  have  the  example  given  in  the  introduction: 

ENABLE(buy(Gl,  ingredients),  prepare(G2,  dinner)) 

Or  to  take  an  example  from  the  glider  tape,  the  agents  need  to  locate  the  parts 
in  order  to  use  them;  i.e.: 

ENABLE(locate(G,  part),  use(G,  part)) 
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Mental  actions,  as  well  as  physical  actions,  participate  in  action  relationships. 
Understanding  directions,  for  instance,  is  a  mental  action  that  enables  the  agents 
to  subsequently  follow  them;  i.e.: 

ENABLE(understand(G,  directions),  follow(G,  directions)) 

As  with  generation,  the  actions  involved  in  an  enable  relationship  may  them¬ 
selves  be  complex  actions.  For  example,  at  the  beginning  of  the  glider  tape,  the 
agents  discover  the  warranty  as  they  are  checking  all  the  parts.  John  then  com¬ 
ments  “If  there’s  any  problem,  I  have  the  bill”.  This  situation  illustrates  John’s 
knowledge  of  disjoined  actions  in  an  enable  relationship:  showing  the  warranty  or 
showing  the  bill  enables  replacing  the  faulty-part;  i.e.: 

GEN-Disjoined((show(G,  warranty)  or  show(G,  bill)), 
show(G,  proof-of-purchase)) 

ENABLE(show(G,  proof-of-purchase),  replace(G,  faulty-part)) 

Another  example  occurs  when  the  agents  attach  the  seat-frame.  They  first  place 
the  seat-frame  in  the  right  position,  acting  simultaneously,  then,  acting  conjointly, 
they  each  place  bolts,  washers  and  nuts  in  their  side  of  the  glider.  Since  the  first 
action  enables  the  second,  we  have: 

GEN-Simult((position(John,  right-side-seat-frame)  A 
position(Paul,  left-side-sear-frame)) , 
position(John&Paul,  seat-frame)) 

ENABLE(position(John&Paul,  seat-frame), 

attach(John,  bolts/washers/nuts,  right-side-seat-frame)) 
ENABLE(position(John&Paul,  seat-frame) , 

attach(Paul,  bolts/washers/nuts,  left-side-seat-frame)) 

GEN-Conjoined((attach(John,  bolts/washers/nuts,  right-side-seat-frame)  A 
attach(Paul,  bolts/washers/nuts,  left-side-seat-frame)), 
attach(John&Paul,  seat-frame,  glider)) 

2.4  FACILITATE 

The  tapes  also  provides  several  situations  where  one  action,  A,  facilitates,  or  makes 
easier,  another,  B.  In  these  cases,  doing  A  brings  about  a  condition  which  makes  the 
(subsequent)  doing  of  B  easier.  Contrary  to  enablement  relationships,  in  facilitate 
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relationships,  A  does  not  have  to  be  done  first  in  order  for  B  to  be  performable;  but 
if  B  is  done  without  A  having  been  done  before,  then  some  other  difficulty  may  be 
encountered.  We  will  denote  this  relationship  FACIL. 

For  example,  at  the  very  beginning  of  the  glider  tape,  the  agents  realize  that 
reading  the  directions  will  help  them  in  their  subsequent  task  of  building  the  glider. 
Using  the  new  relationship  FACIL,  we  can  express  this  as  follows: 

FACIL(read(G,  directions),  build(G,  glider)) 

The  following  utterance  provides  another  example: 

You  can  tell  by  the  fact  that  it’s  a  little  easier  if  we  turn  the  whole  thing 

upside  down. 

FACIL(turn(Gl&G2,  base,  upside-down),  attach(Gl&G2,  rail,  screws)) 

It  is  interesting  to  notice  that  FACILITATE  relations  are  often  explicitly  marked 
in  the  utterance,  e.g.  by  “it’s  probably  good  if” ,  and  “it’s  a  little  easier  if” .  However, 
the  border  between  FACIL  and  ENABLE  is  not  always  evident  from  the  agents’ 
utterances.  In  the  following  utterance,  when  the  agents  are  discussing  the  best  way 
to  fasten  a  bolt,  an  ENABLE,  rather  than  a  FACIL,  relation  seems  appropriate, 
despite  the  fact  that  the  agent  says  “it’s  easier  to”: 

John:  I  guess  it’s  easier  to  hold  it  and  then  turn  it  the  other  side. 

Paul:  Yeah,  once  you  it  get  on,  then  you  can  turn  it. 

ENABLE(hold(Gl,  nut,  left-hand),  tighten(Gl,  screw,  right-hand)) 

GENERATE(tighten(Gl,  screw),  secure(Gl,  rail,  leg-assembly)) 

2.5  PREVENT  relation 

Another  type  of  action  relationship  often  encounted  is  that  of  one  action  A  prevent¬ 
ing  another  action  B.  For  example,  the  child’s  interruptions  bring  about  a  situation 
that  prevents  the  men  from  building  the  glider: 

PREVENT(interrupt(child,  agents),  build(agents,  glider)) 

The  PREVENT  relation  may  be  connected  to  goals  of  maintenance.  For  the 
construction  process  to  be  successful,  for  example,  the  agents  have  to  be  able  to 
work  in  an  undisturbed  environment.  The  child’s  interruptions,  however,  prevent 
this  goal  from  being  maintained,  and  this  in  turn  prevents  the  agents  from  focusing 
their  attention  on  the  construction  process.  This  can  be  expressed  as  follows: 
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PREVENT(interruptions,  undisturbed-environment) 
ENABLE(undisturbed-environment,  build(agents,  glider)) 

A  similar  example  occurs  in  the  following  situation,  where  the  agents  need  to 
maintain  the  wood  from  being  stressed: 

John:  They  say  here  udo  not  over  tighten  bolts,  tighten  only  enough  to  bring 
the  heads  firmly  against  the  wood ”  otherwise  it  starts  to  eat  in  the 
wood  I  assume. 

PREVENT(tighten(bolts,  too-much),wood(unstressed)) 

2.6  CAUSE 

One  last  relation  to  mention  is  that  of  causality.  For  example,  the  agents’  first 
attempt  at  building  the  base  of  the  glider  fails  after  the  structure  collapses  as 
a  result  of  hitting  it  with  a  hammer.  The  failure  then  leads  them  to  decide  to 
coordinate  their  actions.  These  action  relationships  can  be  described  as  follows: 

CAUSE(hit(G,  hammer,  leg-assembly),  detach(leg-assembly,  rail)) 
CAUSE(detach(Ieg-assembly,rai}),  intend(Gl&G2,  coordinate)) 

Other  instances  of  causal  relations  occur  when  the  agents  realize  that  they  are 
running  out  of  washers: 

CAUSE(question(G,  put(G,  washer,  right-arm-assembly)),  count(G,  washers)) 
ENABLE(count(G,  washers),  realize(G,  error)) 

CAUSE(realize(G,  error),  disassembly(G,  glider)) 

Causality  will  be  further  discussed  in  the  last  section  of  this  report. 


3  Action  Relation  Definitions 

The  definitions  that  follow  are  presented  in  the  formalization  developed  during  this 
contract.  That  formalization  suggested  several  simplifications  which  we  are  now 
investigating.  The  modifications  that  result  will  be  (?)  part  of  current  effort. 
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3.1  Action  representation 

Pollack  [P0I86]  adopts  a  3-way  terminological  distinction:  an  act-type  is  a  type  of 
action  (e.g.  calling  the  hospital),  an  action  or  act  is  a  triple  of  act-type,  agent,  and 
time  (e.g.  Joan’s  calling  the  hospital  yesterday  afternoon),  and  an  occurrence  is  a 
realization  of  some  action  (e.g.  Joan  called  the  hospital  yesterday  afternoon),  [cf 
P-41] 

On  the  other  hand,  we  have  suggested  a  2-way  distinction:  occurence  versus  act- 
type.  An  act-type  is  a  type  of  action,  namely  a  singleton,  pair,  triple  or  quadruple 
from  the  following  lattice  of  specialization,  where  a  is  the  act-type  descriptor,  G 
the  agent  performing  a,  T  the  interval  of  time  over  which  a  occurs,  and  O  the  other 
objects  which  play  a  role  in  the  act-type: 

<  a  > 

/  i  \ 

<  a,G>  <  a,0  >  <  a,T  > 

IS  \  /  \1 

<  a,G,0  >  <  a,G,T  >  <  a,0,T  > 

\  I  / 

<  o:,G,0,T  > 

(i)  <  a  >  read 

<  a,  G>  John’s  reading 

<  a,  O,  T>  read  a  novel  today 

<  a,  G,  O,  T>  John’s  reading  a  novel  today 

In  this  representation,  an  act-type  can  be  simply  named,  or  increasingly  specified 
by  other  relevant  arguments.  Pollack,  on  the  other  hand,  typically  represents  objects 
by  “attaching”  them  to  the  act-type,  as  in  (ii),  below,  although  she  does  mention 
an  alternative  representation,  where  objects  are  arguments  to  the  act-type,  as  in 
(iii): 

(ii)  <talk-to-Jane,  Sue,  now> 

(iii)  <talk-to(Jane),  Sue,  now> 

The  notation  in  (iii)  seems  justified  given  that  the  notion  of  agency,  unlike 
that  of  object,  deserves  a  separate  treat  ment  and  should  therefore  be  kept  separate 
from  the  act-type.  Furthermore,  when  there  are  several  objects,  the  notation  in  (i) 
becomes  clumsy  if  they  are  kept  separate  from  the  act  type;  compare  for  example 
<give(painting,  friend),  Sue,  now>  with  <give,  Sue,  painting,  friend,  now>. 

Notice  that  this  difference  in  representation  carries  over  to  the  OCCURS  pred¬ 
icate  to  which  objects  must  also  be  added: 
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(ii)  OCCURS(act-type(object),  agent,  time) 

(iii)  OCCURS(act-type,  agent,  objects,  time) 

We  are  currently  exploring  this  issue.  In  the  present  report,  we  use  the  repre¬ 
sentations  (ii)  and  (iii). 


3.2  Generation 
3.2.1  GEN 

Example  1  Flipping  the  light  switch  to  turn  the  light  on. 

For  single  actions,  we  adopt  Pollack’s  definitions.  She  distinguishes  CGEN  from 
GEN:  CGEN  is  defined  only  in  terms  of  act-types,  a  and  /?,  and  the  “generation- 
enabling  conditions”  C,  whereas  GEN  is  defined  in  terms  of  actions,  i.e.  the  triple 
act-type,  agent  and  time,  <  a,  G,  t>.  Her  definitions  are  as  follows  (cf  p.52] : 

CGEN(a,  0,C)  <=> 

(i)  [V  Gl,  tl  [[HOLDS(C,  tl)  A  OCCURS(a,  Gl,  tl)] 

=>  OCCURS(/?,  Gl,  tl)]  A 

(ii)  3  G2,  t2  [OCCURS(a,  G2,  t2)  A  -OCCURS^,  G2,  t2)]  A 

(iii)  3  G3,  t3  [HOLDS(C,  t3)  A  -OCCURS(/?,  G3,  t3)j] 

GEN(a,/?,  G,  t)  <=>  3  C  (CGEN(a,  0,  C)  A  HOLDS(C,  t)) 


The  previous  example  is  therefore  represented  as  follows  (the  condition  given  is 
simply  illustrative): 

CGEN(flip(G,  light-switch),  turn-on(G,  light),  on(electricity)) 

3.2.2  GEN-Simult 

Example  2  Lucie  and  Chris  holding  both  ends  of  the  piano  to  lift  it  up. 

In  all  following  definitions,  we  make  use  of  the  following  notation:  a  is  an  act- 
type,  a,  runs  from  t  =  1  to  i  =  n,  G  is  an  agent,  G;  runs  from  j  =  1  to  j  =  k, 
n  >  k,  Ga.  is  the  agent  performing  act-type  a,-,  t  is  a  time  interval,  ta.  is  the  interval 
of  time  over  which  acf  type  a,  occurs,  and  te  is  the  interval  of  time  covering  all  ta> 
intervals. 
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CGEN-Simult(a1&  . . .  kan,  (3,  C)  <=> 

n 

(i)  [V  Gj,te  [[(  A  OCCURS(a,,  G«.t  t,))  A  HOLDS(C,  t,)] 

i  =  1 

=►  0CCURS(/3,  Gik  . . .  kGk,  t,)]  A 
n 

(ii)  3  Gj ,te  [(  A  OCCURS(a,-,  Ga.,  te))  A  =OCCURS(/?,  Glk...kGkt  t,)]  A 

i  =  l 

(iii)  3  G,-,t,  (HOLDS(C,  t4)  A  ^OCCURS (/?,  G1&...&Gil  te)]] 

GEN-Simult(ai& . . .  kan,  (3,  Gik . . .  kGk,  t)  •<=>■ 

3  C  [CGEN-Simult(a1&  . . .  kan,  (3,  C)  A  HOLDS(C,  t)] 

Given  this  definition,  and  the  one  presented  later  for  ENABLE,  enablement 
relations  between  the  individual  actions  involved  in  a  GEN-Simult  relationships  are 
excluded.  This  happens  because  of  time  constraints:  if  cq  and  are  >n  a  GEN- 
Simult  relationship,  then  they  occur  at  the  same  time,  if,  on  the  other  hand,  they 
are  in  an  ENABLE  relationship,  then  ax  occurs  before  a2\  therefore,  ax  and  e*2 
cannot  be  both  in  a  GEN-Simult  and  an  ENABLE  relationship. 

Notice  that  the  number  of  agents  participating  in  the  simultaneous  action  is  left 
unspecified.  This  will  be  the  case  of  all  definitions.  Here,  for  example,  there  could 
be  even  just  one  agent:  e.g.  breaking  eggs  into  a  pan  with  one  hand,  and  turning 
the  sauce  in  that  pan  with  the  other. 

Example  2  can  then  be  represented  as: 

CGEN-Simult((lift(Lucie,  left-end)  k  lift(Chris,  right-end)), 
lift(Lucie&Chris,  piano),  not-too-heavy (piano)) 

3.2.3  GEN-sequence 

Example  3  To  make  angel-food  cake,  preheat  the  oven,  make  the  batter,  then  bake 
it. 

CGEN-sequence(a1& . . . &an,  /?,  C)  <=> 

n 

(i)  [V  G,,t4  [[(  A  OCCURS^-,  Ga,,  ta,.))  A  HOLDS(C,  t,)] 

i  =  l 

=»  OCCURS (0,  Gx k...kGk,  t,)]  A 
n 

(ii)  3  Gj ,t£  [(  A  OCCURS(a,,  Ga.,  ta,))  A  =OCCURS(/?,  Gt&  . . .  kGk,  t«)]  A 

t'  =  1 
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(iii)  3  Gy,te  [HOLDS(C,  te)  A  -OCCURS (/?,  Gt& . . .  &G*,  t,)]] 

where  DURING(t,,  te)  and  BEFORE(t,-,  t,+1), 
and  -(3  ay,  a*  ENABLE(ay,  a*)) 

GEN- Sequence  (ai&  . . .  &an,  0 ,  Gi& . . .  &G*,  t)  <=> 

3  C  [CGEN-Sequence(a1&  . . .  &an,  0,  C)  A  HOLDS(C,  t)] 


Notice  that  this  definition  is  exactly  the  same  as  that  of  GEN-Conjoined  except 
for  the  additional  constraint  that  the  time  interval  t,-  occur  before  t,+1,  which  is  not 
required  for  GEN-Conjoined. 

3.2.4  GEN-Conjoined 

Example  4  Sally  and  Peter  setting  the  table. 

CGEN-Conjoined(ai&  . . .  &zan,  0,  C)  <=$■ 

n 

(i)  [V  Gy.t,  [[(  A  OCCURS(o,,  Ga,,,  ta.))  A  HOLDS(C,  t.)] 

i  =  l 

=►  OCCURSQ3,  Gi& . . .  &G*,  t,)]  a 
n 

(ii)  3  Gy, t«  [(  A  OCCURS(a,,  Ga,,  t„,.))  A  -OCCURS^,  Gx& . . . &G*,  te)]  A 

t  =  1 

(iii)  3  Gy,t,  [HOLDS(C,  te)  A  -OCCURS(/?,  Gx& . . .  &Gt,  t,)]j 

where  DURING(t,,  te)  and  -(3  ay,  a*  ENABLE(ay,  a*)) 

GEN-Conjoined(a!<fe  . . .  &a„,  0 ,  Gj&  . . .  &Gt,  t)  <=> 

3  C  [CGEN-Conjoined(a1& . . .  &cotn,  0 ,  C)  A  HOLDS(C,  t)] 


Notice  that  this  definition  is  exactly  the  same  as  that  of  GEN-Simult  except  for 
the  fact  that  the  individual  actions  <  a,,  Gai.,  ta.  >  are  not  necessarily  performed 
at  the  same  time. 

The  previous  example  is  then: 

CGEN-Conjoined([put(Sally,  dishes)  A  put(Peter,  silverware)  A  put(Sally,  glasses)], 
set-table(Sally&Peter),  [on-table(table-cloth)  A  . . .]) 


13 


3.2.5  GEN-Iteration 

a.  Iteration  over  a  set  of  objects 

The  first  type  of  iteration  we  will  consider  involves  iterating  over  a  set  of  objects, 
as  in  the  example  below.  We  describe  it  by  the  action  relationship  GEN-Iteration: 

Example  5  Tightening  a  set  of  bolts  by  tightening  each  one  of  them. 

CGEN-Iteration(a,  obji&  . . .  &obj„,  /?,  C)  (version  1)  <*==> 

n 

(i)  [V  Gy,t,  [[(  A  OCCURS(a(obj,),  Ga.,  tj)  A  HOLDS(C,  te)j 

i  =  l 

=>  OCCURS(/3,  G!&  . . .  &Gjfe,  te)]  A 
n 

(ii)  3  G,-,te  ((  A  OCCURS(a(obji),  G«.,  ta.)  A  -OCCURS(/?,  Gt&  . . .  &Gtl  te)]  A 

i  =  l 

(iii)  3  G;-,te  [HOLDS(C,  te)  A  =OCCURS(/?,  G^  . . .  &G*,  t,)]] 

where  DURING(ta.,  te)  and  ->(3  a,, a*  ENABLE(a;-,  a*)) 

GEN-Iteration(a,  obj^  . . .  &objn,  /?,  G^  . . .  &Gjt,  t)  <=> 

3  C  CGEN-Iteration(a,  obji^  . . .  &obj„,  /?,  C)  A  HOLDS(C,  t)] 

This  definition  is  very  similar  to  that  of  GEN-Conjoined.  What  differs  here  is 
that  instead  of  describing  a  set  of  different  act-types  being  performed,  this  definition 
describes  the  same  act-type,  a,  being  performed  over  a  set  of  objects. 

Given  this  definition,  the  previous  example  is  then: 

CGEN-Iteration(tighten,  boltt& . . .  &boltn,  secure(structure),  available(tools)) 

b.  Iteration  over  agents  and  times 

Just  as  iterations  occur  over  objects  and  act-types,  they  also  occur  over  agents 
and/or  times.  For  example: 

Example  6  Every  member  of  the  team  did  the  exercise. 

Take  this  medicine  every  four  hours. 

These  cases  can  be  handled  by  generalizing  GEN-Iteration  in  the  following  way: 
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C  GEN-Iteration  (a,  iteri&  . . .  &itern,  /?,  C)  (version  2)  <=>■ 

if  iter,  is  an  object,  let  OCCURS(a,,  G*t,  ta,.))]  =  OCCURS(a(obj,),  Ga.,  ta.))| 
if  iter,  is  an  agent,  let  OCCURS(a,-,  Gat.,  t0|.))]  =  OCCURS(o!,  Gt,  tc,))] 
if  iter,  is  a  time,  let  OCCURS(aj,  Ga;,  ta.))]  =  OCCURS(a,  G,  t<))] 
n 

(i)  [V  G,-,t,  [[(  A  OCCURS(a,,  Ga.,  ta,))  A  HOLDS(C,  t«)] 

i  =  1 

==>  OCCURS(/?,  G1(k  . . .  &Gfc,  t,)]  A 
n 

(ii)  3  G,-,t,  [(  A  OCCURS(aj,  Ga.,  ta.)  A  -OCCURS(/?,  Gx&  . . .  &G*,  t,)]  A 

i  =  l 

(iii)  3  Gy,t,  [HOLDS(C,  te)  A  -OCCURS(/?,  Gi& . . .  &G*,  te)]j 

where  DURING(ta;,  te)  and  ->(3  a a*  ENABLE(aJ, a*)) 

GEN-Iteration(a,  iteri&  •  •  •  &itern,  /?,  G1(fc . . .  &Gk,  t)  <=> 

3  C  CGEN-Iteration(a,  iteri&  . . . &iter„,  /?,  C)  A  HOLDS(C,  t)] 

c.  Iteration  over  multiple  sets  of  objects 

The  definition  given  above  for  GEN-Iteration  is  in  fact  a  special  case  of  a  more 
general  definition  which  allows  more  than  one  set  of  objects  to  be  iterated  over. 
Consider  for  instance  the  following  example: 

Example  7  Alex  put  a  nail  in  every  board. 

In  this  situation,  both  a  set  of  nails  and  a  set  of  boards  are  iterated  over. 
Given  its  current  definition,  GEN-Iteration  does  not  handle  this  case.  We  therefore 
introduce  the  term  object  collection  to  refer  to  the  sets  of  objects  that  are  to  be 
iterated  over.  These  sets  typically  correspond  to  different  thematic  roles  of  the  verb 
expressing  the  given  act-type.  In  the  above  example,  we  have  an  object  collection 
consisting  of  all  nails  (i.e.  filling  the  direct  object  position)  and  all  boards  (i.e. 
filling  the  indirect  object  position).  Interation  can  also  involve  objects  filling  other 
thematic  roles,  such  as  instrument  or  destination  for  example. 

The  following  revised  definition  will  handle  these  more  complex  cases  of  iteration. 

It  is  exactly  the  same  as  the  previous  ones,  except  that  o6;‘<,  the  ith  object  being 
iterated  over,  is  replaced  by  obj-colli ,  the  ith  collection  of  objects  being  iterated 
over.  When  only  one  set  of  objects  will  be  iterated  over,  as  is  the  case  most  of  the 
time,  then  obj-colli  will  consist  of  a  single  object  obji. 

CGEN-Iteration(a,  iteri& . . .  &iter„,  /?,  C)  (version  3)  <=> 
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if  iter,  is  a  collection  of  objects, 

let  OCCURS(a„  Ga,,  ta,.))]  =  OCCURS(a(obj-coll<),  Ga,,  ta.))] 
if  iter,  is  an  agent,  let  OCCURS(at,  Ga,,  ta,))]  =  OCCURS(a,  G,,  t,))] 
if  iter,  is  a  time,  let  OCCURS(o:,,  Ga,,  ta,))J  =  OCCURS(or,  G,  t,))j 
n 

(i)  [V  G;,te  [[(  A  OCCURS(a,,  Ga,.,  tj)  A  HOLDS(C,  t,)] 

i  =  l 

=>  OCCURS(/?,  Gx&  . . .  &G*,  te)]  A 
n 

(ii)  3  G;,t,  ((  A  OCCURS(a,,  Ga,.,  t«.)  A  =OCCURS(/?,  G^  . . .  &Gt,  t,)]  a 

i  =  1 

(iii)  3  GJtte  [HOLDS(C,  te)  A  =OCCURS(^,  Gj&.-.&G*,  t,)]] 

where  DURING(ta.,  te)  and  ->(3  o;,  ak  ENABLE(o£y,  a*)) 

GEN-Iteration(a,  iteri&  .  ..&itern,  /?,  G1&...&G  t)  4=> 

3  C  CGEN-Iteration(o:,  iter^  . . .  &:itern,  /?,  C)  A  HOLDS(C,  t)] 

where  OCCURS(a(obj-coll,),  Ga.,  ta.)  =  OCCURS(a(objtl ,  . . obj,t),  Ga,,  ta.) 

with  each  obj,  being  an  argument  of  the  act-type  a, 
and  DURING (ta,,  te), 
and  -i(3  otj,otk  ENABLE(a;,  a*)) 


d.  Scope  of  iteration 

The  definition  we  have  been  refining  is  still  unsatisfactory.  Consider  for  example 
the  following  task: 

Example  8  Fill  all  boxes  and  bring  them  to  the  truck. 

There  are  two  ways  of  performing  this  task:  one  gives  wider  scope  to  the  iteration 
over  objects  and  the  other  to  the  sequence  of  actions  to  be  performed;  in  other  words, 
we  have  the  two  following  possibilities: 

(i)  Fill  all  boxes,  then  bring  them  to  the  truck. 

(ii)  Fill  and  bring  down  one  box  after  the  next. 

We  would  like  to  express  both  these  possibilities  in  the  formalism  developped  so 
far.  Since  the  two  act-types  involved  are  in  a  GEN-Sequence  relationship  (although 
it  is  more  appropriate  to  fill  the  boxes  before  bringing  them  to  the  truck,  the  former 
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action  does  not  enable  the  latter  action  in  any  way),  we  can  do  so  with  the  following 
relationships: 

(i)  CGEN-Iteration(fill(G,  box),  boXi&  . . .  &box„,  fill(G,  set-of-boxes), 

available  (set-of-boxes) ) 

CGEN-Iteration(bring-down(G,  box),  boxi&  . . .  Ajbox„, 

bring-down(G,  set-of-boxes),  not-too-heavy (set-of-boxes)) 
CGEN-Sequence((fill(set-of-boxes)  k  bring-down(set-of-boxes)), 
ready-to-load(truck),  available(truck)) 

(ii)  CGEN-Sequence((fill(G,  box)  &  bring-down(G,  box)), 

prepare-for-loading(G,  box),  available(box)) 
CGEN-Iteration(prepare-for-loading(G,  box),  box!& . . . &boxn, 
ready-to-load(truck),  available(truck)) 

But  suppose  now  that  the  actions  involved  are  the  following: 

Example  9  Bring  down  all  boxes  and  load  them  into  the  truck. 

This  task  can  again  be  accomplished  in  two  different  ways;  but  here,  the  for¬ 
malism  does  not  allow  us  to  express  the  second  possibility,  namely  when  the  set  of 
two  actions  is  iterated  over  the  objects. 

The  problem  is  due  to  the  fact  that  these  actions  are  related  by  an  ENABLE 
relationship  instead  of  an  GEN-Sequence  relationship.  As  can  be  seen  in  the  follow¬ 
ing  representation,  the  relations  as  they  are  now  defined  do  not  provide  a  “handle” 
onto  the  complex  action  consisting  of  one  action  enabling  another.  The  inability 
of  the  relation  to  adequately  represent  this  case  is  a  source  of  future  work  and  we 
expect  ot  explore  an  alternative  formulation  for  a  future  report. 

(i)  CGEN-Iteration(bring-down(G,  box),  boxi<k  . . .  &box„, 

bring-down(G,  set-of-boxes),  ready-to-go(set-of-boxes)) 
CGEN-Iteration(load-into-truck(G,  box),  boxi&  . . .  &boxn, 

load-into-truck(G,  set-of-boxes),  available(truck)) 
CGEN-Sequence((bring-down(set-of-boxes)  k  load-into-truck(set-of-boxes)), 
read-to-go(truck) ,  available(truck) ) 

(ii)  ENABLE(bring-down(G,  box),  load-into-truck(G,  box)) 

CGEN-Iteration(  ???,  box^  . . .  fcboXn,  ready-to-load(truck),  available(truck)) 

e.  Iteration  until/while 
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So  far,  iteration  has  been  restricted  to  cases  of  the  form  “for  t  =  1 ...  n,  do  X,” . 
Other  cases,  however,  are  of  the  form  “do  X  while/until  Y”,  as  in  the  examples 
given  below: 

Example  10 

(x)  Keep  trying  the  number,  until  the  line  is  no  longer  busy. 

(ii)  While  you’re  in  France,  go  to  good  restaurants! 

These  examples  involve  actions  that  are  to  be  repeated  until,  or  while,  a  given 
condition  is  met.  Typically,  an  “until”  construct  involves  an  action  to  be  repeated 
while  the  condition  is  false  and  until  it  is  true,  whereas  a  “while”  construct  involves 
an  action  to  be  repeated  while  the  given  condition  is  true  and  until  it  is  false.  We 
define  a  new  iteration  relation,  GEN-Iteration-test,  to  represent  this  case.  It  is 
defined  as  follows: 

CGEN-Iteration-test(a,  0,  C,  test)  <==> 

(i)  (Y  G;,T,  with  T  max  such  that  HOLDS(test,  T) 

n 

[(HOLDS(C,  T)  A  (  A  OCCURS(a,  Ga,  t,))] 

i  =  1 

=>  OCCURS(/?,  Gi& . . .  &Gt,  T)1  a 
n 

(ii)  3  G,,T  [(  A  OCCURS(a,  Ga,  t,))  A  -OCCURS(/?,  Gt&  . . .  &G*,  T)j  a 

i  =  1 

(iii)  3  Gy,T  [HOLDS(C,  T)  A  -OCCURS {0,  G1&...&Gfc,  T)]J 

(iv) T m«  =  0  =>  -(HOLDS(test,T)) 

where  DURING(ty,  T)  and  -(3  ay,  a*  ENABLE(ay,  a*)) 

GEN- Iteration-test (ai&...&a„,  0,  Gi&.-.&G*,  t,  test) 

3  C  [CGEN-Iteration-test(al&: . . . &a„,  0,  C,  test)  A  HOLDS(C,  t)] 

The  “test”  argument  in  this  definition  will  be  adapted  to  a  true  or  false  propo¬ 
sition  depending  on  whether  a  “while”  or  “until”  construct  is  involved.  For  the 
examples  given  above,  the  arguments  to  CGEN-Iteration-test  would  be  as  follows: 

(i)  CGEN-Iteration-test(dial(number),  Cdll(Sally),  busy(line)) 

(ii)  CGEN-Iteration-test(go-to(restaurants),  enjoy  (yourself),  in(you,  France)) 

There  are  still  cases,  however,  that  do  not  fit  into  this  definition.  These  involve 
actions  to  be  continued,  rather  than  repeated.  For  example: 
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Example  11 

(i)  We  ought  to  think  about  these  instructions  until  we  understand  them. 

(ii)  Keep  working  while  the  system  is  up. 

These  examples  do  not  involve  a  repetition  of  actions,  but  an  action  which  occurs 
over  the  maximal  interval  of  time  during  which  a  given  condition  holds,  namely 
-understand(we,  instructions)  for  (i)  and  up(system)  for  (ii).  We  call  GEN-continue 
the  relation  which  describes  this  type  of  situation.  It  is  defined  as  follows: 

CGEN-continue(a,  P,  C,  test)  <=> 

(i)  (V  G j ,T,  with  T  max  such  that  HOLDS(test,  T) 

[[HOLDS(C,  T)  A  OCCURS(a,  Ga,  t))j 
=>  OCCURS(/3,  Gi&t . . .  &G*,  T)]  A 

(ii)  3  Gy,T  [OCCURS(q,  Ga,  T))  A  -OCCURS (/?,  Gj&  . . .  &G*,  T)]  A 

(iii)  3  Gy,T  [HOLDS(C,  T)  A  -OCCURS {P,  G1(fc  . . .  kGk,  T)]] 

(iv)  TmaI  =  0  =>  -(HOLDS(test,T)) 

where  -(3  ay,  ak  ENABLE(ay,  a*)) 

GEN-continue(a,  P,  G^  . . .  &G*,  t,  test)  <=> 

3  C  [CGEN-continue(a,  /?,  C,  test)  A  HOLDS(C,  t)) 


3.3  ENABLE 

Example  12  Annie  recently  installed  cable  TV  to  be  able  to  see  more  movies. 

CENABLE(a,  /?,  C)  <=> 

[V  Gl,tl,t2,  37  [OCCURS(a,  Gl,  tl)  A 

GEN(a,  (ACHIEVE  (HOLDS  (C,  tl))),  Gl,  tl)  A 
CGEN  (7,0,C)] 

ENABLE(a,  p,  G,  t)  <=>  3  C,  CENABLE(a,  p,  C) 

NB:  the  time  of  a’s  occurring  is  not  necessarily  the  time  of  the  CGEN  of  7  and  p. 

This  definition  says  that  the  occurence  of  a  brings  about  condition  C  and  that 
this  condition  C  is  necessary  for  achieving  P  (via  7).  The  example  given  above  can 
then  be  represented  as  follows: 

ENABLE(install(Annie,  cable-TV),  see(Annie,  more  movies),  available(channells)) 


19 


Unlike  generation,  there  is  no  need  for  defining  new  ENABLE  relations  for  mul¬ 
tiple  actions,  because  multiple  actions  in  an  ENABLE  relation  can  be  expressed 
with  the  existing  GENERATION  and  ENABLE  relations.  The  two  following  ex¬ 
amples,  and  their  representation  (repeated  from  the  previous  chapter),  illustrate 
this  point. 

Example  13 

(i)  You  need  to  show  the  warranty  or  the  bill  in  order  to  replace  a  faulty  part. 

( it )  John  and  Paul  positioned  the  seat-frame,  then  attached  it  with  bolts,  washers 
and  nuts,  each  working  on  one  side  of  the  glider. 

(i)  GEN-Disjoined((show(G,  warranty)  V  show(G,  bill)), 

show(G,  proof-of-purchase)) 

ENABLE(show(G,  proof-of-purchase),  replace(G,  faulty-part)) 

(ii) GEN-Simult((position(John,  right-side-seat-frame)  A 

position  (Paul,  left-side-sear-frame) ) , 
place(John&Paul,  seat-frame)) 

GEN-Conjoined((place(John,  bolts/washers/nuts,  right-side-seat-frame)  A 
place(Paul,  bolts/washers/nuts,  left-side-seat-frame)), 
attach(John&Paul,  seat-frame,  glider)) 

ENABLE(place(John&Paul,  seat-frame), 

attach(John&Paul,  seat-frame,  glider)) 


3.4  PREVENT 

Example  14  Mark’s  playing  the  piano  prevented  Charlie  from  sleeping. 

CPREVENT(a,  0,  C)  <=* 

[V  Gl,tl,t2,  3 7  [OCCURS(a,  Gl,  tl)  A 

GEN(a,  (ACHIEVE  (-HOLDS(C,  tl))),  Gl,  tl)  A 
CGEN  b,/?,  C)] 

PREVENT(a,  0,  G,  t)  <=►  3  C,  CPREVENTa,  0,  C) 

NB:  the  time  of  a’s  occurring  is  not  necessarily  the  time  of  the  CGEN  of  7  and  0. 
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The  PREVENT  relationship  is  very  similar  to  the  ENABLE  relationship.  They 
both  involve  two  act-types,  a  and  0,  related  by  a  generation  condition  C;  the  differ¬ 
ence  is  that  in  the  ENABLE  case,  the  occurence  of  a  brings  about  that  condition, 
wherease  in  the  PREVENT  case,  it  does  not.  This  explains  the  similarity  in  the 
definitions,  the  only  difference  being  in  HOLDS(C,  t)  versus  -'HOLDS(C,  t). 

3.5  FACILITATE 

Example  15  Learning  French  will  make  it  easier  for  you  to  communicate  and  get 
around  in  Montreal. 

CFACIL(a,  0,  C)  <=> 

[3  C,  CENABLE(a,  0 ,  C)  V 
3  Gl,tl,  (-OCCURS(a,  Gl,  tl)j  A 

3  C\  t2,  HOLDS(C’,  t2)  =»  (CGEN(7,  0,  C’)  A 
3  t3,  t3#t2,  HOLDS(C’,  t3)  =►  -.CGEN^,  0 ,  C’)] 

FACIL(a,  0,  G,  t)  <*=>  3  C,  CFACIL(a,  0,  C) 

This  definition  is  a  disjunction.  The  first  disjunct  says  that  there  is  a  condition 
C  such  that  the  occurence  of  a  will  bring  about  that  condition,  thereby  enabling 
the  occurence  of  0.  The  second  disjunct  handles  the  cases  when  a  does  not  occur. 
In  these  cases,  there  is  some  other  condition  C’  under  which  7  will  sometimes 
conditionally  generate  0.  The  “sometimes”  is  represented  by  the  last  implication: 
it  states  that  there  is  a  time  interval  t3  during  which  7  will  not  conditionally  generate 
0. 

The  sometimes  is  necessary  to  convey  the  intuition  that  doing  a  is  “easier”  than 
doing  some  other  action  (namely  7)  that  will  bring  about  the  C’  condition  allowing 
the  occurence  of  0.  If  this  clause  were  not  included,  then  FACIL(a,  /?,  G,  t)  would 
be  equivalent  to 

CENABLE(a,  0 ,  C)  V  CENABLE(7,  0,  C’) 

3.6  Some  open  questions 

3.6.1  HINDER 

Distinguishing  FACIL  from  ENABLE  opens  the  way  for  introducing  HINDER  as  op¬ 
posed  to  PREVENT.  Also,  in  the  same  way  as  PREVENT  is  related  to  --ENABLE, 
so  is  HINDER  related  to  -'FACIL.  These  four  relationships  are  constrasted  in  the 
following  diagram: 
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ENABLE(a,/3) 

HOLDS(C,t)  A  CGEN(-7,/3,C) 

ft 

ft 

PREVENT(a,/?) 
nHOLDS(C,t)  A  CGEN(^,/3,C) 


FACIL(a,/?) 

HOLDS(C,t)  A  helps(C,/3) 

ft 

HINDER(a,/3) 
-iHOLDS(C,t)  A  helps(C,/?) 


where  helps  is  a  short  hand  for  the  second  disjunct  in  the  definition  of  CFACIL. 


The  definition  of  HINDER  then  follows  as  a  dual  of  FACIL,  in  the  same  way 
that  ENABLE  forms  a  dual  with  PREVENT. 


3.6.2  CAUSE 

Example  16  The  glider  structure  collapsed  when  Paul  hammered  the  leg-assembly 
too  strongly. 

Causality  is  intuitively  similar  to  generation  because  both  relations  involve  two 
actions  such  that  the  occurence  of  the  first  results  in  the  occurence  of  second.  They 
are  not  the  same  however,  because  if  GEN(a,/?,  G,  t),  then  a  and  (3  occur  at  the 
same  time,  which  is  not  necessarely  the  case  for  causality.  In  the  following  example, 
the  breaking  of  the  window  occurs  after  the  throwing  the  ball: 

Example  17  Mary  threw  the  ball  up  high  into  the  air;  as  it  came  back  down,  it 
went  right  over  the  balcony  railing  and  through  the  living  room  window,  which  broke 
with  a  loud  noise. 

Causality  is  also  different  from  generation  in  that  GEN(a,/?,  G,  t)  implies 
that  the  same  agent(s)  performed  a  and  f3 ,  which  is  not  normally  the  case  for 
CAUSE(a,/3),  as  the  preceding  examples  show. 

Causality,  in  fact,  often  involves  agentless  actions,  such  as  the  collapsing  and 
breaking  actions  in  the  previous  examples,  or  the  rising  action  in  “putting  yeast  in 
the  dough  caused  the  cake  to  rise”.  The  glider  structure,  the  ball  and  the  cake,  are 
the  agents  of  these  actions,  but  not  in  the  sense  used  in  the  rest  of  this  study  (e.g. 
agents  have  intentions  and  beliefs).  By  dealing  with  agentless  actions,  causality 
relates  events  rather  than  actions. 

Finally,  one  last  difference  worth  mentioning  concerns  intention.  Given  the 
relation,  GEN(a,  (3,  G,  t),  we  expect  the  agent  G  to  intend  to  do  (3  by  doing  a, 
which  is  not  the  case  for  actions  related  by  causality. 

This  relation  is  therefore  quite  different  from  the  other  ones  presented  in  this 
report  and  requires  separate  treatment. 
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3.6.3  Negation 

Agents  may  discuss  actions  or  states  to  be  avoided.  For  example,  the  dialog  during 
the  glider  construction  includes  the  two  following  (non  consecutive)  statements: 

They  say  here  “do  not  over  tighten  bolts,  ...”. 

We’re  not  liable  to  disassemble  it  at  this  stage. 

Negation,  however,  is  a  function  rather  than  a  relation  between  actions  since  it 
takes  act-types  into  act-types,  and  is  therefore  not  a  primary  concern  here. 

3.6.4  States  versus  actions 

It  often  occurs  that  states  enter  into  action  relationships.  The  question  is  whether 
this  is  acceptable  or  not,  and  if  they  are,  how  to  express  such  relationships.  The 
example  involving  the  child’s  interruption  for  example  made  reference  to  the  state 
“undistrubed-environment” . 

There  are  two  possible  answers  to  this  issue.  One  is  to  allow  states  to  enter  into 
action  relations  just  like  actions  do.  The  predicate  ACHIEVE  was  used  by  Pollack 
to  turn  states  into  actions,  e.g.  ACHIEVE(undisturbed-environment).  The  other 
answer  is  to  introduce  new  relationship  names  when  states  are  involved.  For  our 
work,  we  have  chosen  to  use  the  ACHIEVE  predicate. 

3.6.5  Actions  participating  in  several  relationships 

Actions  need  not  participate  in  a  single  action  relationship.  Sometimes,  an  action 
can  be  analyzed  from  several  perspectives,  and  each  one  will  be  represented  by  a 
different  action  relationship.  For  example,  we  can  treat  the  agent’s  reference  to  the 
warranty  either  as  part  of  the  ongoing  plan  of  sorting  out  parts  or  as  an  independent 
plan  of  discussing  the  use  of  a  warranty;  i.e.: 

GEN-disjoined((show(G,  warranty)  or  show(G,  bill)), 
show(G,  proof-of-purchase)) 

GEN-Conjoined((check(G,  warranty)  &:  check(G,  bolts)  &  check(G,  tools)) 
check(G,  parts)) 

3.6.6  Basic  relations  and  relations  of  explanation 

Generation  and  enablement  can  be  viewed  as  “basic”  relations  in  that  they  describe 
facts  about  the  world,  namely  how  actions  are  related  to  each  other.  Other  relations, 
such  as  facilitate  and  prevent  for  example,  seem  less  “basic”  in  that  they  provide 


23 


advice  (facilitate),  or  explanations  (prevent)  about  action  relations  rather  than 
describing  them.  This  difference  might  have  consequences  in  the  way  “recipes”  are 
defined  and  represented.  We  leave  this  topic  to  future  research. 
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